mbp-1043: Client Assertion based authentication using Entra ID#155
Conversation
Signed-off-by: Manuel Lorenzo <mlorenzofr@redhat.com>
There was a problem hiding this comment.
LGTM
I have only one concern related to the ACS and Entra ID federation support. Is there a reason why ACS has been removed from the scope? Users switching from Keycloak to Entra ID would lose ACS SSO.
ACS supports Entra ID integration:
https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_security_for_kubernetes/4.11/html-single/integrating/index#azure-entra-id-federation-overview_integrate-using-short-lived-tokens
Integration with Azure Entra ID was planned for the qtodo, RHTAS, and RHTPA components. ACS was not added, possibly because the component was not yet integrated into the pattern when this planning was done. In this specific case, the feature being added is client assertion support for qtodo, which already had its integration with Azure Entra ID implemented but using a client secret. Note that these integrations with Azure Entra ID are not intended to integrate the pattern compatible with Azure's own resources (or other cloud resources). The goal is to provide support for an additional IdP, besides RHBK, which is the default IdP included with the pattern. |
I see. Thanks for the explanation. |
sabre1041
left a comment
sabre1041
left a comment
There was a problem hiding this comment.
Added one suggestion. Otherwise it works as expected!
Only question is that there is a "feature" for entra-id. Right now as it stands, it assumes/depends on the supply-chain feature. However, if there is a need to just secure the qtodo app, there is no such feature.
Thoughts on how that might want to be handled or just leave it with the instructions alone?
Signed-off-by: Manuel Lorenzo <mlorenzofr@redhat.com>
I've just added a new feature, python3 scripts/gen-feature-variants.py --features entra-id-qtodoI have updated the script documentation in |
sabre1041
left a comment
sabre1041
left a comment
There was a problem hiding this comment.
One quick question. New feature looks good
| Tekton Chains, Pipelines): | ||
|
|
||
| ```bash | ||
| python3 scripts/gen-feature-variants.py --features entra-id-qtodo |
There was a problem hiding this comment.
Do we need to port the following over to the standard entra-id feature?
vault:
jwt:
roles:
- name: qtodo
audience: api://AzureADTokenExchange
subject: spiffe://apps.{{ $.Values.global.clusterDomain }}/ns/qtodo/sa/qtodo
policies:
- apps-qtodo-jwt-secret
There was a problem hiding this comment.
Yes, good catch. I was making several configuration changes while testing and I forgot this one
Signed-off-by: Manuel Lorenzo <mlorenzofr@redhat.com>
3 participants
Summary
keycloakandentraid) with provider-specific configurationChanges
Helm templates and helpers:
qtodo.oidc.urlhelper to support Entra ID tenant-specific URLsqtodo.jwt.audiencehelper to handle Entra ID audience formatAutomation scripts:
scripts/entraid/setup-qtodo-entraid.sh: automated qtodo app registrationscripts/entraid/setup-rhtas-entraid.sh: automated RHTAS app registrationscripts/entraid/setup-rhtpa-entraid.sh: automated RHTPA API and frontend app registrationsscripts/entraid/cleanup-entraid.sh: cleanup script for removing Entra ID resources created by setup scriptsFeature configuration:
scripts/features/entra-id.yamlwith qtodo, RHTPA, and RHTAS Entra ID overridesChart values:
charts/qtodo/values.yamlwith Entra ID provider settingsDocumentation:
docs/oidc/entraid.mdwith:Dependencies
validatedpatterns-demos/qtodo#8
Test plan